Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9701/000035_owner-urn-ietf _Thu Jan 30 23:03:55 1997.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA24132 for urn-ietf-out; Thu, 30 Jan 1997 23:03:55 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA24127 for <[e-mail]>; Thu, 30 Jan 1997 23:03:52 -0500
Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA20164  (mail destined for [e-mail]); Thu, 30 Jan 97 23:03:49 -0500
Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id UAA22463; Thu, 30 Jan 1997 20:03:46 -0800 (PST)
Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id UAA14065; Thu, 30 Jan 1997 20:03:37 -0800 (PST)
Date: Thu, 30 Jan 1997 20:03:37 -0800 (PST)
From: Terry Allen <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [URN] Fragment references.
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Terry Allen <[e-mail]>
Errors-To: [e-mail]

What Ron said, although point 4 may be determined by usage rather
than specification, in the long run.

Regards,
    Terry Allen    Fujitsu Software Corp.    [e-mail]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

>From [e-mail] Thu Jan 30 16:09 PST 1997
From: "Ron Daniel Jr." <[e-mail]>
To: "Ian Higgs [phone]" <[e-mail]>
Cc: "URN Mailing list" <[e-mail]>
Subject: Re: [URN] Fragment references.
Date: Thu, 30 Jan 1997 16:22:59 -0700
X-Msmail-Priority: Normal
X-Priority: 3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Thus spoke Ian Higgs

> Has everybody already agreed that a URN is NOT a form of URI
> and the "/" character does NOT imply a hierarchy as stated in RFC1630?

No. That is pretty much the discussion we are having now.

My current position is that:
 1  URNs are one of the two forms of URI.
 2  URLs are the other form of URI.
 3  URNs are not URLs although they have a similar syntax. In fact,
    we purposefully try to align our syntax with that of URLs in order
    to avoid gratuitous differences. However, we don't adopt all of the
    URL syntax features until we see how they impact the core purpose of
    URNs - persistent, location-independent, resource identifiers.
        (The difference, to me, is that URNs MUST NOT specify any
         resolution-system specific hints, like protocol, port, host, etc.
         while URLs typically do specify such things.)
        (As a side note, the question of whether there really is a
         difference between URNs and URLs has been beaten to death and has
         been declared out of bounds for this list. The URN-WG charter
         assumes there is such a difference, and if there is not then the
         worst that happens to the world is that our work is moot.)
 4  In the absence of good arguments to the contrary, unencoded '/' in URNs
    will end up denoting hierarchy as stated in RFC 1630.
 5  Since we have only just started seriously discussing relative URNs,
    we have not reached consensus on the existance or absence of such a
    good argument.
 6  Since the URN-WG is chartered to produce a URN Syntax draft, and
    neither the charter or URN requirements RFC mentions relative URNs, we
    should not stop the syntax draft while we discuss them.
 7  Therefore, the syntax draft should leave an escape hatch for relative
    URNs.
 8  This is easy to do, we just state that '/' SHOULD (not MUST) be
    %encoded, leaving the door open for people not to encode it if they
    think
      a) they are following the letter and spirit of 1630
      b) whatever we do decide will be in line with 1630

> I think that I missed that.
> If so then there can be no such thing as relative URNs and all URNs
> might as well be 32 digit random numbers (for which there IS a case).

One of the URN requirements is to accomodate legacy namespaces. ISBN,
UPC, VIN, SICI, ISAN, ISWC, ... are all namespaces that identify
important content. Further, they are easy to map to the URN Syntax draft
as it currently exists. There is no need to say all URNs must be 32digit
random numbers. Such a namespace canbe created if you want, but there is
no reason to preclude the ones I cite above.